Follow-up to PR #212 (merged). Addresses two codex review findings.

## Fix 1 — `batched_opacity_blend` needs ray segmentation (codex P1)

The original signature took a single flat `sorted_amplitudes` slice
and emitted a single `out_alpha[ray]` — but a renderer composites N
independent view rays per frame, each with its own front-to-back-
sorted Gaussian sequence. Without per-ray boundaries the
implementation could not know which Gaussians belong to which output
pixel, so it would either composite the same global sequence for
every ray or guess boundaries outside the API.

Adds a CSR-style `ray_offsets: &[u32]` prefix-sum (length `n_rays + 1`)
that segments the flat amplitude buffer into per-ray ranges.
Documented contract:

- `ray_offsets[0] == 0` and `ray_offsets[n_rays] == sorted_amplitudes.len()`
- Empty ray (`ray_offsets[r] == ray_offsets[r+1]`) yields `out_alpha[r] = 0`
- Rays are independent (no cross-ray data dependence) — outer loop
  is trivially parallelizable
- Per-frame amplitude quantization is caller-side; `opacity_lut` is
  a frame-global constant for that pass

Adds three new tests:
- Multi-ray independence (concatenated rays match per-ray calls)
- Empty-ray boundary case (→ α = 0)
- `ray_offsets` invariant debug-asserts

## Fix 2 — `batched_mahalanobis` needs scratch buffer for Cholesky cache (codex P2)

The original implementation note said L was "heap-free via stack or
caller-provided scratch" but the public signature had no scratch
parameter. At the documented `N = 1_000_000` bench size, the
Cholesky cache is `6 * N * size_of::<f32>() = 24 MiB` — not
stack-feasible. The function would either have to allocate
internally (breaking the zero-allocation contract) or recompute
factors per query (breaking the throughput contract).

Adds explicit `cholesky_scratch: &mut [f32]` parameter (length `6*N`)
with documented sizing guidance:

- `N ≤ 8192` MAY use a stack-resident buffer
- `N > 8192` MUST allocate once at engine init and re-use across frames
- The function MUST NOT allocate internally

Matches the `splat-fit` engine and registration-loop pattern where
the scratch is allocated once per `SplatFitActor` mailbox at boot.

## What's NOT in this PR

- Source code: still none. Plan-spec only.
- The W1c primitive-addition contract (all three backends mandatory,
  parity tests gate, VPABSB-correction-style degenerate-input
  documentation) is unchanged — the fix updates the two signatures
  but not the testing or backend invariants.

## Test plan

- [x] Codex P1 (ray segmentation) — added per-ray offset + 3 new tests
      to the contract.
- [x] Codex P2 (Mahalanobis scratch) — added `cholesky_scratch`
      parameter + sizing note + zero-allocation contract.
- [x] Signatures rebalanced (each line-broken with one arg per line +
      sized comments) for readability.
- [ ] Codex re-review on this PR.

…213)

Follow-up to codex review on PR #213. The per-primitive specs at §4.2
(`batched_mahalanobis`) and §4.3 (`batched_opacity_blend`) were
correctly updated in #213, but the module skeleton at the top of the
same file (the `pub fn` declarations in the `src/simd_splat.rs` sketch
around line 50) still advertised the OLD no-scratch / no-ray-offsets
signatures.

Since this document is the implementation handoff for
`src/simd_splat.rs`, an implementer scanning the skeleton first would
recreate the exact APIs #213 was meant to eliminate, leaving the
zero-allocation contract (Mahalanobis) and per-ray segmentation
contract (opacity blend) unenforceable.

## Fix

Updates the two skeleton signatures to match §4.2 and §4.3 exactly,
with cross-references to the per-primitive sections:

- `batched_mahalanobis` — adds `cholesky_scratch: &mut [f32]` (length
  N × 6); inline comment cites §4.2 sizing guidance and the
  "function MUST NOT allocate" contract.
- `batched_opacity_blend` — adds `ray_offsets: &[u32]` (length
  n_rays + 1, CSR-style); `sorted_amplitudes` re-described as flat
  concatenation; `out_alpha` length now `n_rays` (not "per pixel");
  inline comment cites §4.3 segmentation contract.

The two implementations of the §4.2 / §4.3 detailed specs are
unchanged in this PR — this commit only syncs the up-front skeleton
so the two views of the API agree.

## Test plan

- [x] Skeleton + §4.2 + §4.3 now show identical parameter lists.
- [x] Comments on the new parameters cite the section that owns the
      detailed contract (so an implementer who reads the skeleton
      first gets pointed to the contract section).
- [ ] Codex re-review on this PR.